The IP-based IMT network platform (hereinafter referred to as “IP2”) is a network architecture that supports terminal mobility with both route optimization and location privacy (see “Address interchange procedure in mobility management architecture for IP-based IMT network platform (IP2)”, Manhee Jo, Takatoshi Okagawa, Masahiro Sawada, Masami Yabusaki, 10th International Conference on Telecommunications ICT'2003, Feb. 23, 2003, (hereinafter referred to as reference [1])). The corner stone of IP2 is the separation of the Network Control Platform (NCPF) and the IP-Back Bone (IP-BB). In the IP2 architecture, the NCPF controls the IP-BB. The IP-BB consists of IP routers with additional packet processing features, such as temporary packet buffering or address switching. The NCPF consists of signaling servers that command the IP-BB entities intelligently.
Mobile terminals (or mobile nodes hereinafter referred to as “MN”) are assigned permanent terminal identifiers that take the form of an IP address. In addition, MNs are assigned a routing address at the access router (AR) to which it is attached. The routing address is specific to the location of the MN, hence to support location privacy, it shall not be revealed to other MNs. When the MN moves to another AR, a new routing address is allocated to it from the pool of routing addresses available at the new AR. The binding between the MN's terminal identifier (IPha: “IP host address”) and its routing address (IPra: “IP routing address”) is communicated to the NCPF by the AR. More specifically, the address is sent to the local routing manager (LRM) of the MN that manages the MN's movement in the visited network. The LRM, in turn informs the home routing manager (HRM) of the MN about the IPra.
When a MN (MN1) wishes to send a packet to another MN (MN2), MN1 uses MN2's IPha as destination address in the packet and transmits the packet to its AR (AR1). AR1 (termed as sending AR) detects that the packet is addressed to an IPha of MN2 and queries the NCPF, more specifically the HRM of MN2 about the IPra of MN2. The HRM responds to the queries, and the IPra of MN2 is stored in AR1 along with the IPha of MN2. Then, the destination address of the packet (IPha of MN2) is replaced to the IPra of MN2. This operation is referred to as address switching. The packet is then delivered using traditional IP forwarding to the node that owns the IPra of MN2, that is AR2. AR2 (the receiving AR) then replaces the destination of the packet to the IPha of MN2.
One important function of IP2 is AR notification. Whenever MN2 moves to a new AR, the new AR allocates a new IPra for MN2 and the LRM is notified about this new IPra. Then, the LRM updates the HRM, which, in turn, updates AR1. In fact, the HRM updates all ARs that have MNs that send packets to MN2. That is, when an AR queries the HRM about the IPra for MN1, the HRM stores the identity of the querying AR and when the IPra of MN1 changes the HRM updates all such ARs. We term this behaviour as the AR being subscribed for updates of a particular IP2 terminal identifier. Each query the AR makes about an IP2 terminal identifier at the HRM results in the AR being subscribed at the given HRM for the given IP2 terminal identifier.
To decrease the frequency of such updates, the LRM may configure an anchor router (ANR) in the visited network of MN2. The ANR also allocates a routing address for MN1 that is then used by the LRM to update the HRM. Thus, the IPra allocated by the ANR for MN2 is used by AR1 when MN1 sends packets to MN2. When these packets arrive at the ANR, it replaces the destination address to the IPra allocated by AR2 for MN2. Then, the packet is delivered further from the ANR to AR2 using traditional IP forwarding. AR2 switches the destination address back to the IPha of MN2 and delivers the packet to MN2 as without the ANR. Whenever a handoff occurs, the LRM notifies the ANR of the new IPra allocated by the new AR for the MN. In contrast, the HRM is not notified because the IPra allocated by the ANR does not change. Hence, ARs that have MNs transmitting to MN2 also need not be notified at handovers. The HRM (and consequently the ARs) is updated only when the ANR changes. This can happen intentionally due to path optimization or load balancing, or unintentionally when the current ANR fails and another is selected. The use of anchor routers is also defined in “Address interchange procedure in mobility management architecture for IP-based IMT network platform (IP2)” mentioned above.
In addition to destination address switching, the source address of packets can be switched as well. In this case, when MN1 sends a packet to MN2, the AR2 switches the destination address to the IPra of MN2 and the source address to the IPra of MN1. Then, the packet is delivered to AR2 (possibly via an ANR) using IP routing. The AR2 replaces the destination address (IPra of MN2) to the IPha of MN2 and queries the NCPF for the IPha of MN1 based on the source address, that is the IPra of MN1 at this point. The NCPF responds to the queries and AR2 replaces the source address with the IPha of MN1 and then forwards the packet (that is now identical to the original one) to MN2. Source address switching is specified in “Experimental Evaluations of Feasibility and Bottlenecks of IP2 Mobility Management”, Shinta Suigimoto, Masayuki Ariyoshi, Csaba Keszei, Zoltan Turanyi, Andras Valko, Yoshinori Hayashi, Katsutoshi Nishida, Shin-ichi Isobe, Atsushi Iwasaki, IEEE International Conference on Communications (ICC2005), May 16, 2005.
Another option to transmit packets between the ARs is standard IP tunnelling. In this case, the, sending AR (AR1 in our example) does not replace the destination (and source) address of the packet, but encapsulates the packet in a tunnel. The endpoint of the tunnel is the IPra of the destination MN (MN2 in this example). The destination AR (AR2), then, needs only to decapsulate the incoming packets and can transmit them to MN2 right away. We note that, in this case, AR2 does not need to allocate a separate IPra for each MN that is attached to it, but can reuse its own address multiple times.
As summarized, there are three options in transmitting packets from an MN to another MN: (1) destination-only address switching; (2) source+destination address switching; and (3) IP tunneling.
The basic problems for which this invention provides a solution are: how do sending ARs locate the HRM of a destination MN based on the MN's IPha?; and how do such ARs detect if the IPha of the destination MN is in fact a terminal identifier and not a regular IP address.
This is termed as problem #1 in this document and is relevant for all three “transport options” (IP tunneling, destination-only address switching and source+destination address switching).
Problem #2 arises only in case of source+destination address switching. In this case, receiving ARs need to query the IPha of the sending MN based on the IPra of the sending MN. How does receiving ARs identify the relevant NCPF entity to query that might know the binding?.
Since IP2 is a very recent development, no solutions are published to the problems mentioned above.
However, there are some obvious conventional approaches.
For Solving Problem #1:
1. The most obvious solution is to use a single HRM for all MNs. If the queried IPha is not an IP2 terminal identifier then the HRM responds with an error.
2. Another option would be to employ multiple HRMs that are each responsible for a set of MNs. Each HRM advertises the IPha of all of its MNs into the Internet's routing fabric. In this case, the HRM has the IPha of the MN itself. If each HRM advertises the block of terminal identifiers into the Internet's routing fabric, then any packet sent in the Internet having one of the terminal identifiers as IP destination address will arrive at the HRM owning (and advertising) that terminal identifier. Therefore, sending a query using the terminal identifier as IP destination address, will reach the HRM, which, in turn, can respond. On the other hand, however, if there is no HRM at the address, there will be no reply to such a query, except may be for an ICMP Destination Unreachable message. If this is the case, the sender of the query can deduce that “there is no HRM at the IPha (and no answer arrives for the query)”. Then, the querying AR concludes that the IPha is not an IP2 terminal identifier.”
3. A third option would be to use reverse DNS (Domain Network System) to store HRM addresses. If the DNS contains no information under the reverse name corresponding to the IPha, then the querying AR might conclude that the IPha is not an IP2 terminal identifier.
For Solving Problem #2:
These options can partially be applied to problem #2, as well.
1. The use of a single HRM also solves problem #2.
2. The receiving AR that owns the IPra of the destination MN can respond with the IPha of the destination MN. In this case, a specially formatted IP packet addressed to the IPra can be used as query.
3. The DNS can also be used to store IPha addresses.
There are several problems with the above naive approaches.
Limiting the number of HRMs imposes scalability limits on the system, especially if the number of HRMs is at most one.
Using the second approach to solve problem #1 limits the use of IP2 terminal identifiers as routable IP addresses. This limits network design, as the use of IP2 terminal identifiers as IP addresses is necessary when IP2 MNs communicate with non IP2 correspondent nodes (CNs). When such CNs send packets to IP2 MNs, those packets are routed in the legacy Internet based on the MN's IPha in the destination address. When using the second approach for problem #1, packets addressed to the IPha of a MN are routed to its HRM. This forces the HRM to cope with both queries and packets sent by CNs to the MN. This is a clear violation of the separation of NPCF and IP-BB and is highly impractical.
Using the second approach to solve problem #2 results in the use of “specially formatted” IP packets. This either means a specific IPv6 option or some form of protocol/port number combinations. The AR shall test all packets before address switching if they are “specially formatted”. Security is essential in this context, since IPha-IPra mappings reveal location information. It is very hard to secure the query process because each AR (or ANR) must be able to validate if the querying entity is entitled to know the IPha of the MN. Besides the scalability problems of trust management, this approach also violates the NCPF-IP-BB principle, as access shall be controlled by the NCPF and not a router in the IP-BB.
The third approach (using reverse DNS) is problematic, because it overloads the DNS. Any attack on the DNS (e.g., on the root servers) might make IP level communication impossible. In addition, the DNS suffers significant performance problems that are somewhat out of the control of the operator. Finally, in case of problem #2, the DNS need to be quickly updated when a new IPra is allocated. This is also not conforming to the design of the DNS.